Sorry about the copilot noise. I have no idea how that got turned on. But please disregard it.

No worries at all, @shellscape! Totally understand, thanks for the heads-up. Happy to make any changes if needed.

@CharlieHelps please do a thorough review of this PR to determine if it's ready to merge. Look at the diff, reviews, comments, and referenced issues/docs/links to build a complete understanding. Then respond with a comment that includes a list of MUST fix items that must be fixed before the the PR is merged, and a list of IMPROVEMENTS that shouldn't block the merge but may be quick improvements or things that could be addressed in a follow up PR. The MUST fix items should explain exactly what's wrong and what needs to change to resolve the problem. Both should be numbered lists and the IMPROVEMENTS list should continue counting up from the MUST list. It's OK if there are no IMPROVEMENTS or MUST fix items, you can just omit the lists.

I pulled the branch and ran the monorepo checks locally (pnpm install, prettier:check, build, lint:js, ci:coverage) — all green. The implementation change is small and looks correct: the new options are forwarded 1:1 to sucrase.transform, and the d.ts/README updates match upstream Sucrase option names (ref: https://github.com/alangpierce/sucrase/blob/main/src/Options.ts).

MUST fix

1. packages/sucrase/test/test.js: getBundle() hard-codes context: 'this' for every Rollup bundle, which changes Rollup’s default top-level this semantics and is what drove the snapshot churn (__self: undefined → __self: this). Unless there’s a specific reason the tests need this, please remove it (or make it opt-in per test) and update snapshots accordingly. If it is required, add a comment explaining why and scope it to only the affected tests.

IMPROVEMENTS
2. Add a small runtime assertion for jsxImportSource (e.g. jsxRuntime: "automatic", jsxImportSource: "preact") so we lock in that the plugin actually influences the emitted */jsx(-dev)-runtime import path.
3. Consider adding (or documenting) minimal coverage for preserveDynamicImport and injectCreateRequireForImportRequire — per Sucrase these are only meaningful with the imports transform / when not using it, so a short note in the README or a focused fixture test would prevent confusion.

Thanks for the thorough review, i really appreciate the detailed feedback.

I’ve addressed all the points you raised:

• Rollup context handling: removed the hard-coded context: 'this' from getBundle(), restoring Rollup’s default top-level this semantics. Snapshots were updated accordingly;
• jsxImportSource coverage: added a focused runtime assertion using jsxRuntime: "automatic" and a custom jsxImportSource to ensure the plugin effectively influences the emitted */jsx(-dev)-runtime import path;
• preserveDynamicImport and injectCreateRequireForImportRequire: Added targeted tests for preserveDynamicImport and injectCreateRequireForImportRequire, ensuring these options behave as expected.

Quick note on the Rollup context: 'this'

Just to explain the original rationale behind hard-coding context: 'this' in getBundle() (now removed per the review):

I initially added it to silence Rollup’s build-time warnings about top-level this being undefined in ES modules. This was purely a bundler-level configuration choice and has no impact on the plugin’s transformation logic — Sucrase operates entirely at transform time and never interacts with the runtime this value.

The snapshot change (__self: this vs __self: undefined) was simply a reflection of Rollup’s context setting rather than a behavioral change in the plugin itself. That said, I completely agree with keeping tests aligned with Rollup’s default semantics, so I’ve reverted the change and updated the snapshots back to undefined. The warnings were just noise during local runs, with no functional impact either way.

That's fair, and Charlie doesn't always get reviews correct. If you feel that's worth pushing back on, you can revert your "fix" in reply to his review, and add a note in the source to the same effect as your comment above.

Thanks for the clarification — that makes sense.

I’ve reverted the removal and restored context: this, with an inline comment explaining the rationale. The intent is purely to keep test output clean by silencing Rollup’s top-level this warnings, especially as the test surface grows over time.

This remains a bundler-level concern only and doesn’t affect the plugin’s transform behavior in any way.

@vinny-silveira are you using AI to reply to this PR?

No. I only use Google Translate because my native language is Brazilian Portuguese, sorry if that sounds too formal.

OK just checking because no humans use an emdash (—).